Method and system for prioritizing UTOPIA CLAV status polling

ABSTRACT

The present invention is directed to methods and systems for optimizing UTOPIA CLAV polling arbitration. According to an aspect of the present invention, UTOPIA L2 CLAV status polling of each PHY address may be optimized by polling PHY addresses that have not yet indicated an active CLAV status or have just finished a cell transfer so that a CLAV response is required again. According to another aspect of the present invention, UTOPIA L2 CLAV status polling may be arbitrated so faster connection PHY addresses are polled proportionally more often than slower connection PHY addresses. According to yet another aspect of the present invention, if a connection speed no longer has any PHY addresses which require polling, the arbitration may be altered so only the connection speed with PHY addresses which require polling are actually polled. This ensures that the polling bandwidth is used as efficiently as possible.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This patent application claims priority to U.S. ProvisionalPatent Application No. 60/393,739 filed Jul. 8, 2002, which is herebyincorporated by reference herein in its entirety.

FIELD OF THE INVENTION

[0002] The present invention relates generally to optimizing UniversalTest and Operations Physical Interface for Asynchronous Transfer Mode(UTOPIA) Cell Available (CLAV) polling arbitration and, moreparticularly, to prioritizing UTOPIA polling arbitration based onAsynchronous Transfer Mode (ATM) connection speed.

BACKGROUND OF THE INVENTION

[0003] The ATM Forum UTOPIA L2 Technical Specification af-phy-0039.000states that a maximum of 26 Physical Interface (PHY) addresses can bepolled within one cell transfer of 53 bytes. This is assuming that thePHY can give a CLAV response within 1 clock cycle. If additional clockcycles are required for the PHY to respond to a PHY address, then lessthan 26 PHY addresses can be polling within one cell transfer.

[0004] The convention is to use single CLAV status polling to poll up to31 PHY addresses, which is more than the maximum polling bandwidth of asingle CLAV status signal. A common way of increasing the pollingbandwidth is to add additional CLAV status signals to cover the numberof PHY addresses being polled. However, this requires the PHY to supportmore than one CLAV signal. This is known as Multiple Status Polling(MSP). MSP does not address the issue that more PHY addresses mayrequire polling than the maximum achievable polling bandwidth of oneCLAV signal.

[0005] A master device generally has the task of polling the PHYaddresses. A PHY address may return an active CLAV status indicatingthat it is ready for another transfer, unless this PHY is physicallyremoved from the system. The CLAV status response for that specific PHYaddress will not change for successive polls until a cell has beentransferred on that PHY address.

[0006] For each CLAV status signal, more PHY addresses may requirepolling than can be polled within one cell transfer period (e.g., 53clock cycles). For example, a majority of PHY addresses may be deemedslow connection PHY addresses. Periodically, the latency of polling fastconnection PHY addresses may exceed more than a cell period. Forexample, fast connection PHY addresses can indicate up to 100 CLAVstatuses within a period of 2 successive slow connection CLAV statuses.By not checking the fast connection CLAV status often enough, the fastconnection may become congested further back in a network. In addition,if all PHY addresses at one connection speed have indicated an activeCLAV and have yet to be serviced, polling bandwidth will be wasted eachtime the connection speed, with no PHY addresses requiring polling, isselected by a polling arbiter.

[0007] When using Multiple CLAV status polling (MSP), where up to fourindependent PHY CLAV responses are received for each PHY address, CLAVpolling optimization can only occur once all CLAV status for that PHYaddress are flagging an active CLAV status. Once any one of those CLAVstatuses for that PHY address has been serviced where the CLAV statusfor that PHY address is unknown, then all CLAV statuses for that PHYaddress must be checked again.

[0008] MSP increases polling bandwidth by using more CLAV statussignals. However, this requires the PHY to accept more than one CLAVstatus signal or multiple PHYs are required. If multiple CLAV statuspolling is performed, more than one PHY is polled per PHY address soeach PHY address may have more than one CLAV status signal. When one PHYindicates an active CLAV status, the other PHYs using that PHY addressmay not yet have indicated an active CLAV status. This means the PHYaddresses are polled again until all CLAV statuses for that PHY addressindicate an active CLAV status and have yet to be serviced.

[0009] The UTOPIA device within a Helium 210 Chip may poll 31 PHYaddress in a method specified by the ATM forum UTOPIA L2 specificationaf-phy-0039.000. Using a single CLAV status polling method, each PHYaddress is polled in turn, starting at address 0×00 through to address0×1E. The Null PHY address 0×1F is polled between each polled PHYaddress to allow the PHY to respond. The means that only 26 PHYaddresses can be polled for every cell transferred (53 UTOPIA interfaceclock cycles). This polling limitation generally is difficult toovercome but the efficiency of the polling can be improved to ensurethat only PHY addresses, which require polling, are polled.

[0010] Current technology implements three polling specs defined withinthe ATM forum UTOPIA L2 spec af-phy-0039.000. These polling specs areSingle CLAV status polling; Multiplexed CLAV status polling (MSP) using4 CLAV signals; and Direct CLAV status indication using four CLAV statussignals.

[0011] Therefore, there is a need for a more efficient method and systemfor optimizing UTOPIA CLAV polling arbitration.

SUMMARY OF THE INVENTION

[0012] Aspects of the present invention overcome the problems notedabove, and realize additional advantages. In one exemplary embodiment,UTOPIA L2 CLAV status polling of each PHY address may be optimized bypolling PHY addresses that have not yet indicated an active CLAV statusor have just finished a cell transfer so that a CLAV response isrequired again. According to another exemplary embodiment of the presentinvention, UTOPIA L2 CLAV status polling may be arbitrated so fasterconnection PHY addresses are polled proportionally more often thanslower connection PHY addresses. According to yet another exemplaryembodiment of the present invention, if a connection speed no longer hasany PHY addresses which require polling, the arbitration may be alteredso only the connection speed with PHY addresses which require pollingare actually polled. This ensures that the polling bandwidth is usedefficiently.

[0013] According to one particular exemplary embodiment, a method forprioritizing status polling based on connection speed comprises thesteps of determining a number of fast connection PHY addresses;determining a number of slow connection PHY addresses; calculating apoll ratio based on the number of fast connection PHY addresses and thenumber of slow connection PHY addresses; and arbitrating status pollingbased at least in part on the poll ratio for at least one pollingperiod.

[0014] In accordance with other aspects of this particular exemplaryembodiment of the present invention, one or both of the fast connectionPHY addresses and the slow connection PHY addresses are softwareconfigurable; the fast connection PHY address is configured to beapproximately 155 Mb/s link; the slow connection PHY address isconfigured to be a T1/E1 1 Mb/s to 2/5 Mb/s link; the poll ratiocomprises a plurality of poll ratios; the polling is restricted to thePHY addresses that are connected; status polling is arbitrated at adifferent poll ratio for each polling period; the poll ratios include0/100, 25/75, 50/50, 75/25, 100/0 wherein each poll ratio representsfast connections to slow connections; the polling period comprises a twoclock cycle polling; the poll ratio is further based on one or more of anumber of connections, type of connection and bandwidth distribution.

[0015] According to another particular exemplary embodiment, a systemfor prioritizing status polling based on connection speed comprises apoll ratio module for calculating a poll ratio based on the number offast connection PHY addresses and the number of slow connection PHYaddresses; and an arbitrate status polling module for arbitrating statuspolling based at least in part on the poll ratio for at least onepolling period.

[0016] The accompanying drawings, which are incorporated in andconstitute a part of this specification, illustrate various embodimentsof the invention and, together with the description, serve to explainthe principles of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The present invention can be understood more completely byreading the following Detailed Description of the Invention, inconjunction with the accompanying drawings, in which:

[0018]FIG. 1 illustrates an example of CLAV polling in accordance withan embodiment of the present invention.

[0019]FIG. 2 illustrates an example of CLAV polling in accordance withan embodiment of the present invention.

[0020]FIG. 3 illustrates an example of CLAV polling where Receive (Rx)PHY addresses are polled in accordance with an embodiment of the presentinvention.

[0021]FIG. 4 illustrates an example of CLAV polling where Transmit (Tx)PHY addresses are polled in accordance with an embodiment of the presentinvention.

[0022]FIG. 5 is an exemplary flowchart illustrating a method foroptimizing CLAV status polling, in accordance with an embodiment of thepresent invention.

[0023]FIG. 6 is an exemplary diagram illustrating a system foroptimizing CLAV status polling, in accordance with an embodiment of thepresent invention.

[0024]FIG. 7 is a diagram illustrating fast connection PHY addressgeneration and slow connection PHY address generation in accordance withan embodiment of the present invention.

[0025]FIG. 8 is an exemplary flowchart illustrating a method forprioritizing status polling, in accordance with an embodiment of thepresent invention.

[0026]FIG. 9 is an exemplary diagram illustrating a system forprioritizing status polling, in accordance with an embodiment of thepresent invention.

[0027]FIG. 10 illustrates a basic polling arbitration (50/50 ratio) inaccordance with an embodiment of the present invention.

[0028]FIG. 11 illustrates an enhanced polling arbitration (50/50 ratio)in accordance with an embodiment of the present invention.

[0029]FIG. 12 is an exemplary flowchart illustrating a method foroptimizing CLAV status polling, in accordance with an embodiment of thepresent invention.

[0030]FIG. 13 is an exemplary diagram illustrating a system foroptimizing CLAV status polling, in accordance with an embodiment of thepresent invention.

[0031]FIG. 14 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated.

[0032]FIG. 15 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated.

[0033]FIG. 16 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated.

[0034]FIG. 17 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated.

[0035]FIG. 18 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated.

[0036]FIG. 19 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated.

DETAILED DESCRIPTION OF THE INVENTION

[0037] The following description is intended to convey a thoroughunderstanding of the invention by providing a number of specificembodiments and details related to optimizing UTOPIA CLAV pollingarbitration. It is understood, however, that the invention is notlimited to these specific embodiments and details, which are exemplaryonly. It is further understood that one possessing ordinary skill in theart, in light of known systems and methods, would appreciate the use ofthe invention for its intended purposes and benefits in any number ofalternative embodiments, depending upon specific design and other needs.

[0038] Polling may involve a master device (e.g., a level 2 masterdevice, etc.) that constantly polls a bus to determine the status of aplurality of slave devices. In particular, a transmit master device maypoll the bus to determine which slave devices are able to receive acell. Further, a receive master may poll the bus to determine whichslave devices are ready to transmit a cell. Ports that are enabled willbe polled where ports are enabled by setting bits in the TX_andRX_POLL_ENABLE registers.

[0039] Status polling may be performed by using a simple two-clocksequence that uses one clock status and one clock select to collect theinformation. This process may continue even while datatransmission/reception is taking place. For UTOPIA Level 2 Master (L2M)polling by a Transmit (Tx) master, the master may poll the UTOPIA bus bydriving the Tx address lines and may continue even while it istransmitting a cell. Slave receivers may respond by asserting theTX_CLAV line if the receivers are able to receive a cell. Once themaster has determined that a slave receive is able to receive a cell,the master no longer polls that device. For L2M polling by a Receive(Rx) master, the master may poll the UTOPIA bus by driving the Rxaddress lines. The master may continue polling even while it isreceiving a cell. Slave receivers may respond by asserting the TX_CLAVline if the receivers have a cell available for transmission. Once themaster has determined that a slave transmitter has a cell ready fortransmission, the master no longer polls that device.

[0040] According to an embodiment of the present invention, UTOPIA L2CLAV status polling of each PHY address may be optimized by polling PHYaddresses that have not yet indicated an active CLAV status or have justfinished a cell transfer so that a CLAV response is required again. ThePHY CLAV polling bandwidth may be utilized more efficiently to workaround the limitations of a maximum of 26 PHY addresses that can bepolled in one cell period (e.g., one ATM cell period).

[0041] The repeated CLAV status polling of a PHY address with an activeCLAV status may be considered as wasted polling bandwidth. According toan embodiment of the present invention, a basic polling method may beenhanced, in one respect, where PHY addresses, which have not indicatedan active CLAV status or have just finished a cell transfer, are polled.As a result, the CLAV status polling bandwidth is ensured to limitpolling to PHY addresses where the CLAV status could change.

[0042] Two examples of the enhanced CLAV polling are illustrated in FIG.1 and FIG. 2. FIG. 1 illustrates an enhanced CLAV polling in accordancewith an embodiment of the present invention. Utxclk/Urxclk 102represents UTOPIA transmitter clock/UTOPIA receiver clock.UtxAddr/UrxAddr 104 represents UTOPIA transmitter address/UTOPIAreceiver address. UrxClav/UtxClav 106 represents UTOPIA receive cellavailable/UTOPIA transmitter cell available. Untxen/Unrxen 108represents UTOPIA transmitter enable/UTOPIA receiver enable. Asillustrated in FIG. 1, some addresses show an active CLAV status 110, asshown by UrxClav/UtxClav 106. For example, address 00, 01, 02 and 04have responded with an active CLAV status. Thus, these addresses do notneed to be polled again until the address is serviced. Addresses 03, 05and 06 indicate an inactive CLAV status 120. Therefore, the inactiveaddresses are polled again as shown by 130 until these addresses show anactive CLAV status, in accordance with an embodiment of the presentinvention. After all enabled addresses have been polled, the addresseswith inactive CLAV status are polled again, namely addresses 03, 05 and06.

[0043] For example, more than 26 PHY addresses may be enabled forpolling where none have asserted an active CLAV response. In the exampleof FIG. 1, a worst case polling loop, where none of the 31 PHY addressesshow an active CLAV response, will exceed the polling bandwidth of 26PHY address in one service cycle. But, on average, polling loops will bewithin the maximum bandwidth of 26 PHY addresses per service cycle dueto the time it takes to service existing active CLAV requests.

[0044] Enabled PHY addresses may flag an active CLAV where a celltransfer has not taken place or finished. When there are no PHYaddresses requiring polling, the NULL PHY address will be polled until aPHY address requires polling. FIG. 2 illustrates a situation when no PHYaddress requires polling. In this situation, a null PHY address may bepolled (e.g., do nothing). In this example, two addresses remain to bepolled as shown by 210, namely addresses 03 and 06. After address 06indicates an active CLAV status, only one address 03 remains to bepolled. The remaining address 03 is polled until an active CLAV statusis received, as shown by 220. When no addresses remain to be polled,there is no need to do anything, as shown by a series of IF addresses230.

[0045] For a receive, the CLAV status for a specific PHY address may bepolled again within the last 4 bytes of a previous transfer. This givesan interface the opportunity of performing back to back cell transferson the same PHY address with a minimal setup delay between transfers.For a transmit, the CLAV status for a specific PHY address may be polledimmediately after the previous transfer finishes.

[0046]FIG. 3 illustrates an example of CLAV polling where Receive (Rx)PHY addresses are polled in accordance with an embodiment of the presentinvention. In particular, FIG. 3 illustrates a situation where a Rx PHYaddress is polled again once a previous Rx PHY address has been serviced(e.g., within 4 bytes of end of transfer) in accordance with anembodiment of the present invention. For example, when an address isserviced, the CLAV status of the address may be checked within the lastword of transfer (e.g., 4 bytes) on the receive side, as shown by 310.Addresses just serviced may be polled again to obtain a CLAV status, asshown by 320. When the address is serviced, the CLAV status of theaddress may be checked within the last word of transfer, as shown by330.

[0047]FIG. 4 illustrates an example of CLAV polling where Transmit (Tx)PHY addresses are polled in accordance with an embodiment of the presentinvention. In particular, FIG. 4 illustrates a situation where a Tx PHYaddress is polled again once a previous Tx PHY address has been servicedin accordance with an embodiment of the present invention. In thisexample, when an address is serviced, CLAV status cannot be checkeduntil the end of a transfer, as shown by 410. As shown in FIG. 4, theaddress just serviced may be polled again to obtain CLAV status, asshown by 420. When the address is serviced, CLAV status of the addressmay be checked within the last word of transfer, as shown by 430.

[0048]FIG. 5 is an exemplary flowchart illustrating a method foroptimizing CLAV status polling, in accordance with an embodiment of thepresent invention. At step 510, a plurality of PHY addresses may bepolled to determine CLAV status. At step 512, the CLAV status for eachone of the plurality of PHY addresses may be received. At step 514,whether the CLAV status could change for each PHY address may bedetermined. At step 516, each PHY address with a CLAV status that couldchange may be re-polled. For example, the CLAV status that could changemay include an inactive CLAV status and a completed cell transfer. Thus,the step of re-polling may further include the step of re-pollingaddresses with an inactive CLAV status and/or the step of re-pollingaddresses having completed a cell transfer. Further, re-polling of PHYaddresses having an active CLAV status may be avoided thereby conservingresources.

[0049]FIG. 6 is an exemplary diagram illustrating a system foroptimizing CLAV status polling, in accordance with an embodiment of thepresent invention. System 600 may include a Polling Arbiter 610 foroptimizing cell available (CLAV) status polling of a plurality ofphysical interface addresses. Polling Arbiter 610 may include a PollingModule 612, a CLAV Status Module 614, a Determining Module 616, aRe-Polling Module 618 and Other Module 620. Polling Module 612 may polla plurality of PHY addresses to determine CLAV status. CLAV StatusModule 614 may receive the CLAV status for each one of the plurality ofPHY addresses. Determining Module 616 may determine whether the CLAVstatus could change for each PHY address. Re-Polling Module 618 mayre-polling each PHY address with a CLAV status that could change. Asdiscussed above, the CLAV status that could change may include aninactive CLAV status and a completed cell transfer. Thus, the Re-PollingModule 618 may further include re-polling addresses with an inactiveCLAV status and/or re-polling addresses having completed a celltransfer. Further, re-polling of PHY addresses having an active CLAVstatus may be avoided thereby conserving resources. Other Module 620 mayprovide other functionality associated with optimizing CLAV statuspolling.

[0050] In practice, different ports may be running different speedlinks. For this reason, a mechanism for allowing priority to be given tohigher-speed ports is provided in accordance with an embodiment of thepresent invention. For simplicity, the above descriptions of pollinghave not taken any account of this option, which is available to bothtransmit and receive masters. There are at least two stages to theprioritization process, according to an exemplary embodiment. First, anyport may be designated as a high-speed port. This may be done by settingthe appropriate “per-port” bit in a TX_PORT_SPEED register or aRX_PORT_SPEED register. Second, a poll ratio between the high and lowspeed ports may be determined. This may be set by a POLLRATIO field in aTX_CONTROL register and a RX_CONTROL register. Generally, there are morelow-speed ports than high speed ports. A poll ratio of an embodiment ofthe present invention may provide prioritization for optimal performanceand efficiency. For example, in an exemplary conventional system wherethere are four low-speed ports and one high-speed port, the high-speedport may be polled four times before all of the low speed ports havebeen polled.

[0051] According to another embodiment of the present invention, UTOPIAL2 CLAV status polling may be arbitrated so faster connection PHYaddresses are polled proportionally more often than slower connectionPHY addresses, according to one example. The speed of slave devices maybe different, as communication speeds often differ. The CLAV statusindication to service latency of fast PHY connections may be reducedand/or avoided, due to the CLAV status for faster connection PHYaddresses being known before the last PHY address service, whether fastor slow, has finished being serviced.

[0052] As a result, less slow connection PHY addresses may be polled percell period without increasing the polling to service latency of theslow connection PHY address. At one extreme example, the differences inconnection speeds may mean a faster connection speed PHY address runningat 155 MB/s which may indicate a CLAV status up to 100 times more oftenthan a single slow connection PHY address.

[0053] Faster connection PHY addresses may be polled proportionally moreoften to ensure that a fast connection PHY address status may beavailable within one cell period. The differentiation between what isregarded as a fast connection PHY address and what is a slow connectionPHY address is software configurable. According to one example, anassumption is that a 155 Mb/S link is a fast connection compared to aT1/E1 1 Mb/s 2.5 Mb/s link, which is a slow connection PHY address.Other determinations of slow and fast connections may be applied inaccordance with the present invention.

[0054] The 155 Mb/s link may indicate an active CLAV status up to 100times within the period of successive Ti/E1 CLAV status. With thisassumption, a UTOPIA PHY address connected to a Ti/E1 link which isflagging CLAV may be left for a reasonable amount of time beforecongestion further back in the network will occur due to the PHYsrunning out of buffer space.

[0055]FIG. 7 is a diagram illustrating fast connection PHY addressgeneration and slow connection PHY address generation in accordance withan embodiment of an embodiment of the present invention. An output froma PHY address poll enabler register 710 and an output from a PHY addressspeed register 712 may be received and combined with an output from aCLAV status register 714. PHY address poll enable register 710 and PHYaddress speed register 712 may mask the CLAV status register(s) 714 toensure that polling is restricted to PHY addresses which are connectedthereby ensuring efficient round robin checking. The combined output maybe received at a port polling address round robin logic 716 for fastconnections as well as a port polling address round robin logic 718 forslow connections. As shown, 702 is directed to fast connection PHYaddress generation and 704 is directed to slow connection PHY addressgeneration. A polling address arbiter 720 may receive a request poll forfast connections and slow connections and respond with poll grantedsignals to each respective port polling address round robin logics 716,718. A next poll address may be generated by the polling address arbiter520, which may then be combined with a next service address forgenerating a UTOPIA PHY address.

[0056] A polling address arbiter of an embodiment of the presentinvention provides a priority polling which is dependant on a pluralityof ratios, as detailed below. For example, for every four pollingperiods (or other predetermined number of polling periods), the ratiomay arbitrate which priority input will receive a majority of thepolling. The ratios may be determined by how many connections, type ofconnections, how the bandwidth is to be distributed and/or otheradditional factors and considerations. The number of ratios to beimplemented as well as the value of the ratios themselves may vary inaccordance with an embodiment of the present invention. The ratiosdescribed below are exemplary only. Arbitration % Ratio Value(Fast/Slow) RATIO 0  0/100 Only slow connection PHY addresses accepted 125/75 1 fast connection PHY addresses serviced to every 3 slow PHYaddresses 2 50/50 2 fast connection PHY addresses serviced to every 2slow PHY addresses 3 75/25 3 fast connection PHY addresses serviced toevery 1 slow PHY addresses 4 100/0  Only fast connection PHY addressesaccepted 5 Reserved Reserved 6 Reserved Reserved 7 Reserved Reserved

[0057] The ratio of polling generally has a dramatic effect on thesystem performance. A critical time may include the number of PHYaddresses that may be polled in the time it takes to transfer a cell; inparticular, how many times a fast connection PHY address is polled.

[0058] For each cell transferred, the following arbiter results may beachieved for a 2 cycle polling. Arbitration Ratio Fast Connection PHYSlow Connection PHY (fast/slow) addresses polled addresses polled  0/100 0 26 25/75 6-7 19-20 50/50 13 13 75/25 19-20 6-7 100/0  26  0

[0059] In the following exemplary scenarios, the following pollingresults may be achieved for each cell period of 53 clock cycles.

[0060] In this exemplary scenario detailed below, all 31 PHY addressesare connected and enabled with 2 clock cycle polling where the PHYaddress connections include 2 fast connection PHY addresses and 29 slowconnection PHY addresses. Arbitration Ratio (fast/slow) Result  0/100 26slow connection PHY addresses serviced ONCE 25/75 2 fast connection PHYaddresses serviced AT LEAST 3 times, 19-20 slow connection PHY addressesserviced ONCE 50/50 2 fast connection PHY addresses serviced AT LEAST 6times, 12 slow connection PHY addresses serviced ONCE 75/25 2 fastconnection PHY addresses serviced AT LEAST 9 times, 7 slow connectionPHY addresses serviced ONCE 100/0   2 fast connection PHY addressesserviced 13 times

[0061] In another exemplary scenario detailed below, 14 PHY addressesare enabled and connected, with 2 clock cycle polling where the PHYaddress connections include 2 fast connection PHY addresses and 12 slowconnection PHY addresses. Arbitration Ratio (fast/slow) Result  0/100 12slow connection PHY addresses serviced AT LEAST TWICE 25/75 2 fastconnection PHY addresses serviced AT LEAST 3 times, 12 slow connectionPHY addresses serviced AT LEAST ONCE 50/50 2 fast connection PHYaddresses serviced AT LEAST 6 times, 12 slow connection PHY addressesserviced AT LEAST ONCE 75/25 2 fast connection PHY addresses serviced ATLEAST 9 times, 6-7 slow connection PHY addresses serviced ONCE 100/0  2fast connection PHY addresses serviced 13 times

[0062] In yet another exemplary scenario detailed below, 8 PHY addressesare enabled and connected, with 2 clock cycle polling where the PHYaddress connections include 8 fast connection PHY addresses and no slowconnection PHY addresses. Arbitration Ratio (high/low) Result  0/100 NOPHY ADDRESSES POLLED as no PHY addresses present 25/75 6-7 fastconnection PHY addresses serviced ONCE, NO slow connection PHY addressesserviced ONCE 50/50 8 fast connection PHY addresses serviced AT LEASTONCE, NO slow connection PHY addresses serviced ONCE 75/25 8 fastconnection PHY addresses serviced AT LEAST TWICE, NO slow connection PHYaddresses serviced ONCE 100/0  8 fast connection PHY addresses servicedAT LEAST 3 times

[0063]FIG. 8 is an exemplary flowchart illustrating a method forprioritizing status polling, in accordance with an embodiment of thepresent invention. At step 810, a number of fast connection PHYaddresses may be determined. At step 812, a number of slow connectionPHY addresses may be determined. At step 814, a poll ratio based on thenumber of fast connection PHY addresses and the number of slowconnection PHY addresses may be calculated. At step 816, status pollingmay be arbitrated based at least in part on the poll ratio for at leastone polling period. The fast connection PHY addresses and/or the slowconnection PHY addresses may be software configurable. The poll rationmay include a plurality of poll ratios. Further, status polling may bearbitrated at a different poll ratio for each polling period. Exemplarypoll ratios may include 0/100, 25/75, 50/50, 75/25, 100/0 where eachpoll ratio represents fast connections to slow connections.

[0064]FIG. 9 is an exemplary diagram illustrating a system forprioritizing status polling, in accordance with an embodiment of thepresent invention. A system 900 for prioritizing status polling based onconnection speed may include a Polling Address Arbiter 910. PollingAddress Arbiter 910 may include a Receive Request Module 912, a PollRatio Module 914, an Arbitrate Status Polling Module 916, a Grant Module918, and Other Module 920. Receive Request Module 912 may receive one ormore request poll signals. Poll Ratio Module 914 may calculate a pollratio based on the number of fast connection PHY addresses and thenumber of slow connection PHY addresses. Arbitrate Status Polling Module916 may arbitrate status polling based at least in part on the pollratio for at least one polling period. Grant Module 918 may generate oneor more poll grant signals. Further, a next poll address may beforwarded. Other Module 929 may provide other functionality associatedwith prioritizing status polling.

[0065] When combining the inventive concepts discussed above, the CLAVpolling bandwidth may be optimised further. In particular, if aconnection speed no longer has any PHY addresses which require polling,the arbitration may be altered so only the connection speed with PHYaddresses which require polling are actually polled. This ensures thatthe polling bandwidth is used as efficiently as possible. In addition,for multiple CLAV status polling, polling a PHY address may be stoppedor avoided if all CLAV statuses for that PHY address have indicated anactive CLAV status and have yet to be serviced. Further, the pollingbandwidth may be maximized when used along with polling arbitration.

[0066] The UTOPIA device within the GlobespanVirata® Corporation'sHelium™ 500 chip, as described in detail below, may poll 31 PHYaddresses using a method specified by the ATM forum UTOPIA L2specification af-phy-0039.000 with the enhancements of variousembodiments of the present invention. According to an embodiment of thepresent invention, a single CLAV status polling method may considerconnection speed, whether an active CLAV status has been indicated, andwhether a PHY address has or has not been serviced. For each connectionspeed, each PHY address which has not indicated an active CLAV statusmay be polled in turn, starting at address 0×00 through to address 0×1E,for example. A Null PHY address 0×1F may be polled between each polledPHY address to allow the PHY to respond. A polling arbiter may thendecide which connection speed the PHY address is to be polled next.

[0067] If fast and slow speed connections are being used, the pollingarbiter may be set at a polling ratio of 25/75, 50/50 or 75/25, forexample. Other ratios may be implemented in accordance with embodimentsof the present invention. The number of poll ratios may vary as well.According to an embodiment of the present invention, PHY addresses arenot polled again once a PHY address has indicated an active CLAV statusuntil the PHY address has been serviced. If all PHY addresses on oneconnection speed have indicated an active CLAV status and have not beenserviced yet, then the polling cycles for that connection speed arewasted, as illustrated in FIG. 10. FIG. 10 illustrates a basic pollingarbitration (50/50 ratio). As shown, a first set of high speed ports1010 are polled, then a first set of low speed ports 1012. At the secondset of high speed ports 1014, only null ports (e.g., 1F) are beingpolled since there are no high speed ports requiring polling. A secondset of low speed ports 1016 are polled, in accordance with the pollingratio.

[0068] Polling bandwidth may be used more efficiently by switching thearbitration to one connection speed until the other connection speedindicates PHY addresses have been serviced (e.g., a PHY address requirespolled again), as illustrated in FIG. 11. FIG. 11 illustrates anenhanced polling arbitration (50/50 ratio) in accordance with anembodiment of the present invention. As shown, a first set of high speedports 1110 are polled, then a first set of low speed ports 1112 arepolled. Since there are no high speed connection ports that requirepolling, a second set of low speed ports 1114 may be polled. Further,additional low speed ports 1116 may be continued to be polled. Thus,ports (e.g., low speed ports) that have not yet given a CLAV status arepolled.

[0069] If all PHY addresses on both connection speeds have indicated aCLAV status and no PHY address has yet been serviced, then the pollingmay revert to polling the default PHY address of 0×1F (or other defaultaddress).

[0070] According to an embodiment of the present invention, multipleCLAV status polling may check multiple PHY's CLAV statuses for each ofthe 31 PHY addresses. A PHY address may be skipped from the pollingprocedure if all of its CLAV statuses are flagging an active CLAV. Onceone of those CLAV statuses for that PHY address is serviced then all theCLAV statuses for that PHY address may be polled again since at leastone status is unknown.

[0071]FIG. 12 is an exemplary flowchart illustrating a method foroptimizing CLAV status polling, in accordance with an embodiment of thepresent invention. At step 1210, a first connection speed having a firstassociated set of PHY addresses may be determined. At step 1212, asecond connection speed having a second associated set of PHY addressesmay be determined. At step 1214, status polling may be arbitrated basedat least in part on a polling ratio involving the first connection speedand the second connection speed. At step 1216, the first and secondassociated set of PHY addresses may be polled to determine a CLAV statusfor each PHY address, according to the polling ratio. At step 1218,whether each PHY address of the first and second connection speedrequires polling may be determined. Step 1220 may involve re-polling ata connection speed wherein at least one PHY address of the connectionspeed requires polling. The polling ratio may be based on a number ofPHY addresses of the first connection speed and a number of PHYaddresses of the second connection speed. Further, the polling ratio maybe updated based on a number of PHY addresses requiring polling.

[0072]FIG. 13 is an exemplary diagram illustrating a system foroptimizing CLAV status polling, in accordance with an embodiment of thepresent invention. A system 1300 may include a polling arbiter 1310 foroptimizing cell available (CLAV) status polling. The Polling arbiter1310 may include a Determine Connection Speed Module 1312, a Poll RatioModule 1314, an Arbitrate Status Polling Module 1316, a Polling Module1318, a Determine PHY Address Status Module 1320, a Re-Polling Module1322, and Other Module 1324. Determine Connection Speed Module 1312 maydetermine a first connection speed having a first associated set of PHYaddresses and a second connection speed having a second associated setof PHY addresses. Poll Ratio Module 1314 may calculate a poll ratioinvolving the first connection speed and the second connection speed.Arbitrate Status Polling Module 1316 may arbitrate status polling basedat least in part on a polling ratio. Polling Module 1318 may poll thefirst and second associated set of PHY addresses to determine a CLAVstatus for each PHY address, according to the polling ratio. DeterminePHY Address Status Module 1320 may determine whether each PHY address ofthe first and second connection speed requires polling. Re-PollingModule 1322 may re-poll at a connection speed wherein at least one PHYaddress of the connection speed requires polling. Other Module 1324 mayprovide other functionality associated with optimizing CLAV statuspolling.

[0073] GlobespanVirata® Corporation's Helium™ 500 communicationsprocessor (Helium 500 CP) is a high performance ATM and InternetProtocol (IP) processor. Helium 500 CP offers an extended range of I/Ooptions and features, providing great flexibility as well as an extendedchoice of operating systems for an application developer. Helium 500 CPuses a dual processor architecture to provide an efficient and flexiblesolution for a range of applications. The main CPU, the ProtocolProcessor (PP), runs the operating system and application software. Timecritical tasks, such as servicing of I/O ports, ATM switching and ATMtraffic shaping are handled by a second processor, the Network Processor(NP). This dual processor design frees the main CPU from constantinterrupts, enabling very efficient use of the processor and memorybandwidth for application processing tasks. The Network Processor itselfis made more efficient by the inclusion of independent Direct MemoryAccess (DMA) controller blocks in each of the high-performance I/Oblocks. Use of these reduces the NP processing to the start and end of apacket only.

[0074]FIG. 14 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated. Inparticular, FIG. 14 illustrates a block diagram of Helium 500 CPincorporating the inventive aspects discussed above, in accordance withthe present invention. The Helium 500 CP has at least three functionalsubsystems, which include a Processor subsystem, a Network subsystem anda Peripherals and Services subsystem. The Processor subsystem comprisesa dual Advanced Reduced Instruction Set Computing (RISC) Machine (ARM®)processor, shared memory and a common Static Random Access Memory (SRAM)interface block. The Network subsystem provides high performance I/Oconnections and associated services. The Peripherals and Servicessubsystem provides a programmable General Purpose I/O (GPIO) connection,management and debug connections and additional services for theprocessors, including hardware encryption/decryption block for optimalnetwork performance. This block also includes the system clocks andtimers. These functional sub-systems are linked by high-performancebuses, all of which operate at the same clock speed as the processors.

[0075] For its main CPU, the Helium 500 CP uses the powerful ARM920T®processor running at 166 or 133 MHz, depending on product variant. Largedata and instruction caches and a highly efficient Synchronous DynamicRandom Access Memory (SDRAM) controller further enhance performance. Inaddition, the inclusion of a memory management unit (MMU) allows the useof a wider choice of operating systems for application development.Applications for the Helium 500 CP can be developed using any of theATMOSTM operating system, from GlobespanVirata® Corporation; VxWorkS™,from Wind River™, Linux™ and others. For its second processor, theHelium 500 CP uses the high-performance ARM966E-S® processor, alsorunning at 166 or 133 MHz, depending on product variant. For maximumdata transfer efficiency, the NP shares SRAM and the SDRAM controllerwith the PP.

[0076] The Helium 500 CP incorporates a wide range of I/O blocks, makingit an ideal platform for applications requiring cell, frame and TimeDivision Multiplexing (TDM) connectivity. In addition to its on-boardI/O capabilities, the Helium 500 CP provides expansion ports dedicatedto state-of-the-art peripheral devices. Its External Peripheral Bus(EPB) supports Motorola™ or Intel™-type peripheral devices, as well asPersonal Computer Memory Card International Association (PCMCIA)peripheral devices. For very high performance peripherals, the Helium500 CP includes a Peripheral Component Interconnect (PCI) expansion busand system controller. The PCI bus has a direct path to system memory,allowing peripherals to DMA data directly.

[0077] Each of the Network I/O blocks, except for the TDM block,includes a dedicated DMA engine. These share a dedicated DMA bus,through which they connect directly to the SDRAM controller. The DMAsystem allows data transfers between the I/O blocks and external SDRAMto be performed with minimal intervention from the processors.

[0078] The Helium 500 communications processor has the following keyfeatures: choice of operating system support from ATMOS® fromGlobespanVirata® Corporation, VxWorkS™ from Wind River™; and Linux™;Protocol Processor (PP) as the main CPU: High-performance ARM® 9 withMMU, 16 KB data cache, 16 KB instruction cache; separate ARM® 9 NetworkProcessor (NP) off-loads time-critical tasks from PP, 32 KB private“tightly coupled” SRAM onchip: 16 KB data, 16 KB instruction space;product variants with 166 MHz and 133 MHz processor speeds, memorysystems designed to optimize throughput of data: additional 32 KB SRAMshared between the two processors, high performance SDRAM controller,shared by the two processors, operates synchronously with processors;supports up to 128 MB external DRAM; high-performance DMA systems,optimized for efficient handling of communications data: eachhigh-bandwidth I/O block has its own dedicated DMA engine, a commonfull-speed 32 bit bus links the DMA engines directly to the SDRAMcontroller; in normal operation, the NP will initiate a DMA transferwhere no further NP processing is required until the transfer hascompleted, functions such as checksum calculation and byte alignment canbe performed while the data is being transferred, Nextport logic blockdetermines which I/O port service request has the highest priority,removing need for any polling of I/O ports by the processor, similarly,a Next Interrupt Request (IRQ) block prioritizes outstanding IRQswithout processor intervention; dual 10/100 Mb/s Ethernet Media AccessControllers (MACs); Encryption/Decryption hardware accelerator (withInternet Protocol Security (IPSec) support), supported by hardwarerandom number generator: encrypts and decrypts data as defined in FIBSBUS 81, single or triple Data Encryption Standard (DES) modes; supportsElectronic Code Book (ECB), Cipher Block Chaining (CBC), Output Feedback(cryptography) (OFB)-64, incorporates Secure Hashing Algorithm accordingto FIPS PUB 180-1 (SHA-1) hardware assist function; two high-speedmulti-function serial units (MFSUs), each of which is configured tooperate in one of three modes: High-Level Data Link Control (HDLC) modeconforms to q.921 and ISO/IEC 2209:1993, supports bus mode, V.35 andX.21 fixed links operating at up to 50 Mb/s, hardware support for 16 and32 bit Frame Checking Sequence (FCS); 1.432 Mode is in accordance withInternational Telecommunication Union-Telecommunications (ITU-T) 1.432interface standard at 50 Mb/s data rate; High-speed Serial UniversalAsynchronous Receiver and Transmitter (UART) mode, supporting both3-wire and 5-wire interfaces (software or hardware flow control) at 1.5Mb/s data rate, suitable for connection to Bluetooth devices; TDM blockprovides two independent TDM interfaces with flexible HDLC controllers,each offering data rate up to 8 Mb/s; up to 256 programmable time-slots,up to 32 simultaneous HDLC streams, with single or multiple time-slotsand programmable number of bits per slot; ability to support “quad”framer devices (carrying up to four T1/E1 channels); UTOPIA master/slaveport offers UTOPIA level 1 or 2 ports, master or slave operation,provides up to 31 ports, first 8 ports can be configured for high-speedoperation; Network Timing Reference (NTR) recovery function, can alsoprovide local network clock generation; PCI expansion bus forhigh-speed, flexible peripheral connection: 32 bit, 33 MHz bus, PCImaster or slave operation, in-built arbiter with support for up to twoperipheral devices for operation in master mode, PCI Rev 2.2 complaint;External peripheral bus (EPB) for co-processor or peripheral expansion:supports 8, 16 and 32 bit bus widths, offers support for i960, Motorola,Intel and PCMCIA bus formats, programmable strobes allows support forother formats; Universal Serial Bus (USB) 1.1 slave port operates at 12Mhz; Programmable GPIO block with up to 64 I/O pins available, eachconfigurable as input or output, allows interfacing to local device(e.g., for driving indicators or sensing switches); support for IEEE1149.1 boundary scan and ARM® In-Circuit Emulator (ICE) debugger;Compatible with GlobespanVirata Corporation Helium family of productsand IP Service Operating System (ISOS) software; designed throughout forlow-power operation, many operational blocks can be put into standbymode to save power.

[0079]FIG. 15 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated. Inparticular, FIG. 15 is a UTOPIA block functional overview incorporatingthe inventive features discussed in detail above. The Helium 500 CPprovides a single UTOPIA interface which can operate in the followingfour modes: UTOPIA level 2 Master (L2M) up to 31 ports; UTOPIA Level 2Slave (L2S) single port (port number between 0 and 30); UTOPIA Level 1Master (LIM) single port (port 0); and UTOPIA level 1 slave (LIS) singleport (port 0).

[0080] As shown in FIG. 15, the main data path through the block passes(in the reverse direction) from the external connections, through theUTOPIA Rx processor, to the First In First Out (FIFO) block. The DMAengine, which forms part of the block, transfers data from the FIFO ontothe DMA bus and then directly into SDRAM. The transmit data path issimply the reverse of this, passing from the FIFOs through the UTOPIA Txprocessor block. In addition, the UTOPIA block control logic isconnected to the Network I/O bus, and can also access the FIFOs. A cellcounter unit is also provided; this tracks the number of cellstransmitted and received on each port. The block provideshighly-flexible support for the prioritization of some ports forhigh-speed operation. Separate FIFOs are provided for Transmit andReceive data. The organization of the FIFOs depends on the operatingmode of the block; however each active port is always provided with atleast a single cell (e.g., 13-word) buffer. The FIFO hardware providessynchronization between the different clock domains of the UTOPIA block,where this is required.

[0081]FIG. 16 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated. Inparticular, FIG. 16 illustrates the relation of the UTOPIA block to theHelium 500 CP architecture. This diagram indicates how the UTOPIAblock's DMA engine transfers data directly to external SDRAM, via theDMA bus and the SDRAM controller, without any intervention from theprocessors. It also indicates the direct connections between the UTOPIAblock and the Next Port and Cell Header Decoder blocks of the Networksubsystem.

[0082]FIG. 17 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated. Inparticular, FIG. 17 illustrates a SDRAM block diagram. The SDRAMcontroller provides a high-performance interface to external SDRAMs forcode and data storage. It operates at the processor core clock frequencyof 166 or 133 MHz, and is compatible with the Joint Electronic DeviceEngineering Counsel (JEDEC) standard JED2421 for interfacing tosynchronous DRAMs. The controller has three internal ports allowing theDMA controller, the NP and the PP to access SDRAM via separate internalbuses. The controller features independent write data and addressbuffering on each port (e.g., 16 word data buffer on each port (DMA, NPand PP ports); 1 address buffer per port); intelligent arbitrationbetween the three ports where the arbitration scheme dynamically adjuststo the load conditions and also guarantees maximum latency requirementsat each port; and advanced SDRAM interleaving where the SDRAM controllerre-orders memory cycles to optimize data transfer. It does this byautomatically interleaving banks of memory with in the SDRAM devices.The overhead of preparing one bank is hidden during data movement to theother. This process is entirely transparent to the user. Other featuresinclude data coherency guarantee where the controller guarantees datacoherency between ports (e.g., data in a write buffer on one port can beaccessed by a read from another port) and support for memory devicessizes of 64 Mb, 128 Mb and 256 Mb, each of which can be 8, 16 or 32 bitswide, the maximum memory that can be connected is 4×256 Mb (128 MB).Generally, access to the external SDRAM is 32-bits wide. Another featureincludes a power down mode where a low power mode drastically reducesthe power consumed by external SDRAM devices.

[0083]FIG. 18 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated. Inparticular, FIG. 18 illustrates a core system including processors andDMAs. A principle use of the DMA system is for the NP to transfer datapackets and cells between SDRAM buffers and network ports. The DMAsystem may include a DMA engine within each of the high performance I/Oblocks and a dedicated DMA bus linking these engines to the SDRAMcontroller. This enables the NP to interleave operations efficiently ondifferent devices without being stalled by SDRAM accesses. The DMAchannels carry out functions such as checksum calculation and bytealignment as the data is transferred. The PP may also make use of DMAchannels, for example to access devices attached to the EFB.

[0084]FIG. 19 is a schematic diagram of a hardware architecture in whichthe inventive aspects of the present invention may be incorporated. Inparticular, FIG. 19 is a DMA block diagram. The DMA system reduces thereliance on NP when transferring data between high-speed I/O modules andthe SDRAM memory. The system includes a DMA controller within each ofthe high-speed I/O modules, connecting directly to the Transmit andReceive FIFOs within the module; a dedicated DMA port on the SDRAMcontroller; and a dedicated high-speed 32-bit DMA bus, linking the DMAcontrollers to the SDRAM controller. DMA transfers between the networkmodule FIFOs and the SDRAM take place in parallel with other NPoperations; NP processing is required only at the start and end of thepacket or cell. Each DMA controller is able to discard packets that donot need to be received. A single DMA transfer across the bus (e.g., aburst) is between one and 16 words. The 16 word limit prevents anydevice from “hogging” the DMA bus. Where larger DMA data transfers arerequired they are split into multiple 16-word bursts, automatically.Write performance is enhanced by buffering in the SDRAM controller. Theaddressable memory range of the DMA controllers is 256 MB, although theSDRAM controller limits the usable address range of 128 MB.

[0085] The DMA system illustrated in FIG. 19 includes two exemplary I/Oblocks. Additional I/O blocks may be implemented. The control blockwithout each of the I/O blocks is connected to the Network I/O. Forclarify, these connections have been omitted from the diagram. The SDRAMcontroller shown in FIG. 19 provides write buffering on its input fromthe DMA bus, optimizing the performance of write operations.

[0086] Data transfers within the Helium 500 CP will normally take placeunder the control of the Network Processor (NP), responding to servicerequests provided through the Next Port mechanism. The Helium 500 CPallows other modes of operation; for example, DMA transfers could bedriven by interrupts from the I/O ports. DMA transfers involve theinter-operation of the I/O block and the DMA block. Each I/O block whichuses the DMA engine has two groups of registers, the I/O block-specificregisters and the DMA registers. The I/O block-specific registerscontrol data transfers (e.g., transmission and reception) between theI/O block and the external network and may be highly block specific. TheDMA registers control DMA data transfer between the I/O block and theSDRAM and are essentially the same for each block, although not all ofthe DMA registers are provided in all I/O blocks. To set up a networkdata transfer (e.g., transmit or receive), I/O block-specific registerswill be used to set up the transmit or receive operations and the DMAregisters will be used to set up the data transfer between the I/O blockand the SDRAM. Data is transferred directly between SDRAM and the FIFOsof the I/O block, under the control of the DMA engine and without anyintervention from the NP. Burst transfers across the DMA bus are limitedto a maximum of 16 words; if the requested transfer is longer than thisit will be split into multiple 16-word bus transfers, and DMA busarbitration will take place after each burst. With transmit operations,signaling within the DMA system ensures that data is only transferredacross the DMA bus if the FIFO has space to receive it. The I/O block isresponsible for detecting the recovering from data over- or under-runconditions, and may abort the DMA transfer (e.g., if it is unable totransmit data from the FIFO to free up space for the requested datatransfer). When the entire data transfer has been completed the DMAblock raises a service request to indicate the fact. The I/O block maythen need to perform additional processing to complete the operation.

[0087] While the foregoing description includes many details andspecificities, it is to be understood that these have been included forpurposes of explanation only, and are not to be interpreted aslimitations of the present invention. Many modifications to theembodiments described above can be made without departing from thespirit and scope of the invention.

[0088] The present invention is not to be limited in scope by thespecific embodiments described herein. Indeed, various modifications ofthe present invention, in addition to those described herein, will beapparent to those of ordinary skill in the art from the foregoingdescription and accompanying drawings. Thus, such modifications areintended to fall within the scope of the following appended claims.Further, although the present invention has been described herein in thecontext of a particular implementation in a particular environment for aparticular purpose, those of ordinary skill in the art will recognizethat its usefulness is not limited thereto and that the presentinvention can be beneficially implemented in any number of environmentsfor any number of purposes. Accordingly, the claims set forth belowshould be construed in view of the full breath and spirit of the presentinvention as disclosed herein.

1. A method for prioritizing status polling based on connection speed,the method comprising the steps of: determining a number of fastconnection PHY addresses; determining a number of slow connection PHYaddresses; calculating a poll ratio based on the number of fastconnection PHY addresses and the number of slow connection PHYaddresses; and arbitrating status polling based at least in part on thepoll ratio for at least one polling period.
 2. The method of claim 1,wherein one or both of the fast connection PHY addresses and the slowconnection PHY addresses are software configurable.
 3. The method ofclaim 2, wherein the fast connection PHY address is configured to beapproximately 155 Mb/s link.
 4. The method of claim 2, wherein the slowconnection PHY address is configured to be a T1/E1 1 Mb/s to 2/5 Mb/slink.
 5. The method of claim 1, wherein the poll ratio comprises aplurality of poll ratios.
 6. The method of claim 1, wherein the pollingis restricted to the PHY addresses that are connected.
 7. The method ofclaim 1, wherein status polling is arbitrated at a different poll ratiofor each polling period.
 8. The method of claim 5, wherein the pollratios include 0/100, 25/75, 50/50, 75/25, 100/0 wherein each poll ratiorepresents fast connections to slow connections.
 9. The method of claim1, wherein the polling period comprises a two clock cycle polling. 10.The method of claim 1, wherein the poll ratio is further based on one ormore of a number of connections, type of connection and bandwidthdistribution.
 11. A system for prioritizing status polling based onconnection speed, the system comprising: a poll ratio module forcalculating a poll ratio based on the number of fast connection PHYaddresses and the number of slow connection PHY addresses; and anarbitrate status polling module for arbitrating status polling based atleast in part on the poll ratio for at least one polling period.
 12. Thesystem of claim 11, wherein one or both of the fast connection PHYaddresses and the slow connection PHY addresses are softwareconfigurable.
 13. The system of claim 12, wherein the fast connectionPHY address is configured to be approximately 155 Mb/s link.
 14. Thesystem of claim 12, wherein the slow connection PHY address isconfigured to be a T1/E1 1 Mb/s to 2/5 Mb/s link.
 15. The system ofclaim 11, wherein the poll ratio comprises a plurality of poll ratios.16. The system of claim 11, wherein the polling is restricted to the PHYaddresses that are connected.
 17. The system of claim 11, wherein statuspolling is arbitrated at a different poll ratio for each polling period.18. The system of claim 15, wherein the poll ratios include 0/100,25/75, 50/50, 75/25, 100/0 wherein each poll ratio represents fastconnections to slow connections.
 19. The system of claim 11, wherein thepolling period comprises a two clock cycle polling.
 20. The system ofclaim 11, wherein the poll ratio is further based on one or more of anumber of connections, type of connection and bandwidth distribution.21. A computer readable medium, the computer readable medium comprisinga set of instructions for prioritizing status polling based onconnection speed and being adapted to manipulate a processor to:determine a number of fast connection PHY addresses; determine a numberof slow connection PHY addresses; calculate a poll ratio based on thenumber of fast connection PHY addresses and the number of slowconnection PHY addresses; and arbitrate status polling based at least inpart on the poll ratio for at least one polling period.